AI 只是手段，不是目的。

所以在進行 AI 專案之前應該先問，「我們公司需要導入AI 嗎？」

而這個解答需要有兩方面的知識，知道 AI 能做什麼的人，以及能夠判斷是否能產生商業利益的該領域專家，這也是本系列文推廣 AI 基礎知識的目的之一。

AI 專案流程

1. 評估與計畫
2. 收集資料
3. 訓練模型
4. 部署模型
5. 風險管理

2. 到 4. 就是機器學習的專案流程，但是商業化的 AI 專案會多了 1. 和 5.

評估與計畫

該導入 AI 嗎？

具體而言會做下面的評估：

• 商業面（是否能產生商業利益）
  • 可否降低成本
    例如：任務自動化
  • 可否增加收益
    例如：推薦系統
  • 可否成為新的商業模式
    推出新的服務或產品
• 技術面（知道 AI 能做什麼）
  • 評估要做什麼，可以從下面幾個方向思考：
    • 將工作分成幾個小任務，做任務自動化
      小型自動化適合作為試點項目（Pilot project）。
      短期內能夠看到成果增加動力。
    • 公司的痛點？
      是否能作為長期以來公司問題點的解決對策。
    • 公司如何為客戶提供核心價值？
      是否符合客戶的需求，是客戶想要的服務。

      精品業就有不錯的例子，詳見 Day 28 介紹。

  • 確定要做什麼之後，是否能達到要求
    • 要做的事情可以只靠 Rule-based 的程式就辦到嗎？如果可以，有必要用 AI 嗎？

      像是產品表面龜裂，如果單靠 Rule-based 設定一個刮痕為固定的像素大小的話是辦得到，但是沒法列舉所有可能性。不過透過 AI 學習，只要標記刮痕就可以學習判別缺陷。

    • 初期即便預測準確性無法達到要求，但是今後這種需求會變多的話，是否能夠持續改進來符合需求？
  • 需要多少資料
    • 資料通常越多越好，不過小資料就足以開始小型專案。
    • 單純的數據資料，還是也需要標籤資料做監督式學習？

    有時候初期還沒有標籤會先使用 預測 + Rule-based，比如說裝置的某數值透過預測，再生產1000次會到一個界限，但是因為沒有標籤不知道其實需要作設備維護了，會先用經驗法則設個閥值。

  • 需要多少時間／人力

決定 AI 系統的提供方式

AI 系統通常不會是一次性的產品，而是作為服務持續更新學習。
分為兩種形式提供服務：

• 雲端運算（Cloud Computing）
  透過網路，將輸入傳給遠端的伺服器做模型運算，再透過 WEB API 回傳取得預測結果。

• 邊緣運算（Edge Computing）
  需要即時性回饋，直接在資料收集的現場做模型運算取得預測，根據需求有時會透過網路上傳資料或更新模型。
  例如：工廠，自駕車。

以製造業來說，由於資料機密和即時性的緣故，工廠大多採邊緣端，但如果是製造商本身的整合性分析服務，會比較適合在雲端上進行。目前 AI 系統的使用者界面如果採用網頁 App 的形式，就容易在雲端（遠端伺服器）及邊緣端（本地端伺服器）切換運用。

配合 AI 專案重新設計作業流程

也就是我們一般說的 企業流程再造 （BPR，Business Process Re-engineering）
避免導入 AI 在某個地方節省了成本，反而在其他地方增加了成本這種本末倒置的問題。

比方說為了將資料上傳到雲端，反而需要有人到無網路的裝置現場把資料備份出來造成人力成本的增加。

建立 AI 團隊還是外包？

初期的試行性小專案，機器學習工程師可以是內部人員也可以是外包，但是資料科學家比較沒辦法，因為涉及到很多專門領域的知識（domain knowledge），而當專案大到某個程度的時候會需要建立自己的內部 AI 團隊，一般大公司會傾向自己建立 AI 團隊。

以製造業來說，自家的製程工程師應該是最清楚自家產品有什麼問題，像這種就不太可能外包給外面的人來處理。

AI 團隊的架構

除了以商業觀點（能不能賺錢）帶領團隊的負責人之外，通常會有軟體工程師，機器學習工程師，以及資料科學家（通常是該產業的專家）。小型專案的場合可能會是一個人身兼數職，而大型專案的場合分工會比較明確。而無論是什麼專案，確保彼此的溝通無礙是重要的，畢竟當客戶提到想要用教師學習（教師あり学習，監督式學習的日文講法），又或者提到想要用評價指標的 F值 為多少當專案的驗收時，聽不懂的話會蠻尷尬的。

目前合作的大型 AI 專案，儘管成員有些不是工程師，但清一色都是 G檢定合格起跳，確保彼此的認知是相同且有共通的語言。像上述監督式學習的日文叫有教師的學習，非監督式學習叫做無教師學習，只知道英文名稱的話沒辦法很順利地和日本成員們溝通。（所以我才被逼去考試）

評估專案（Assessment）

確認是否有類似的具體事例，模型實際準確度可以到達多少。
而專案需要的資料是否可以收集得到，也是評估的要點之一。

訂定專案目標

決定好要做什麼之後，要決定整個專案的目標，透過目標數字可以具體量化成果。

• 回歸
  用 MSE （均方誤差）等方法評估預測誤差要在多少以內。
• 分類
  用混淆矩陣選擇一個適當的評價指標。
• 物體偵測
  可以用預測的速度和 mAP 來決定目標。
• 自然語言處理
  可以用各種 NLP Task 評分。

如果是自駕車系統，安全性可能才是首要目標。而專案目標可以透過可視化的儀錶板（Dashboard）隨時透過圖表作直觀地評估。

收集資料

怎麼收集資料昨天已經介紹過了，這邊要著重的是收集資料時要注意什麼事情。

• 資料的使用條件

  • 公開資料集的商用許可
    有些大型資料集只提供學術使用不可商用，要注意避免觸法。

  • 網路爬蟲收集的資料
    有些網站會直接在網站聲明禁止爬蟲，或是只允許一部分可以使用。

  • 資料使用契約
    特別是個人資料保護法，除了當地法規，如果針對國外也提供服務的話，也要遵守該國的個資法。例如歐盟規定的 GDPR（通用數據保護條例）。

    而日本政府 2018年訂定了「AI 資料的利用契約指導原則」，明訂了 AI 開發時各種階段提供的資料或由 AI 生成及收集的資料，合作夥伴（程式開發者，資料提供者）之間的使用權，所有權的契約制定方法。

    台灣目前沒看到類似的法規（有錯請指正）。通常法規部分會由公司的法務顧問做調查。

• 資料的偏頗
  在 Day11 有提到，如果都只準備貓的圖像，狗的圖像非常少就會造成準確率高的假象，一般公開的大型資料集的資料非常廣泛比較不會有這個問題，而自己收集的時候就要注意不能只準備想要預測的對象資料。另外沒發生過的事情沒法預測，比方說想要預測馬達故障，但是收集的資料從來沒發生過馬達故障，這樣是沒有辦法做預測的。所以資料要盡可能大範圍（各種可能性）且均衡（不要偏重某一類資料）的收集。

• 資料的品質：垃圾進，垃圾出（Garbage in，garbage out）
  如果給錯誤的資料，得到也只是會是錯誤的預測。
  所以奇特的數字（比方說溫度 9999度），奇怪的空值（數字的部分為空白），都要事先做資料清理。

• 資料的偏見
  詳細的會在 Day 29 介紹，這邊簡單說明可能發生的事情。

  • 圖像偏見
    如果收集的資料圖像都是白人，那麼做生成模型 GAN 時，即便輸入是黑人圖像，生成圖像時也有可能被轉換成白人。
  • 自然語言處理的偏見
    如果用監督式學習讓 AI 做招聘人員的書面審查，如果過去都不曾採用懷孕婦女的話，AI 也會學習這樣的偏見，拒絕懷孕婦女的求職申請。

資料加工

• 貼標籤（Annotation）
  這邊特別要注意的是「標註指引」，也就是監督式學習時對資料貼標籤時的統一規則，避免有的人因為圖像的頭像太小不貼，怎樣叫太小？又或者是背景圖像模糊就不貼，怎樣叫模糊？沒有一定的規定，會導致不同人進行資料貼標籤的混亂，造成 AI 學習的不一致。

立即複習

1. 雲端運算和邊緣運算通常哪個運算資源比較多，哪個即時性比較好？
2. 回歸和分類請各舉一個方法做模型的評估。
3. 因為公司在歐洲沒有分公司，所以不用遵守歐盟的 GDPR，對還是錯？
4. 請簡單說明為什麼要配合 AI 專案重新設計作業流程。
5. 準確率高但是非目標的類別都分類錯誤的問題是因為非目標的資料太多還太少？

答案

3. 錯，境外公司只要有提供服務也需遵守。